Transaction in memory object store

ABSTRACT

Techniques for rating and committing events in an event processing system are provided. Events can be rated at a rating system according to information that is stored locally on the rating system. Rated events can be stored in a database system with these rated events being utilized to, among other things, restore information that is stored locally on the rating system.

This application claims priority to provisional application 60/366,827,filed Mar. 22, 2002, which is hereby incorporated by reference.

BACKGROUND OF THE INVENTION

The present invention relates to event processing systems. Morespecifically, the invention relates to event processing systems thatprocess events, such as for billing, in real time.

With the dramatic increase in the number of on-line and wirelesstransactions (or events), accounting techniques have also had to evolvein order to keep pace with the consumer market place. In general, eventprocessing systems receive events, rate the events according to aparticular rating scheme and generate the appropriate billinginformation for the consumers. Although these steps are common to mostall event processing systems, there are a variety of event processingsystems currently in use.

An event processing system can operate as a batch system. FIG. 1 showsan event processing system that processes events 101 in batches. Arating engine 103 rates events 101 according to information receivedfrom a database 105. Database 105 can include, for example, customerinformation 107, accounts receivable (A/R) 109 and events 111.

Typically, batch systems rate events at non-peak hours of the day orweek. As an example, a batch system could be configured to rate eventsat midnight each day. At midnight, all customer information 107 and A/R109 may be sent to rating engine 103. Rating engine 103 then processesall the events and sends the appropriate changes to database 105including events 111 that occurred.

Batch event processing systems are suitable in many applications.However, the systems include a number of disadvantages such as the datais inaccurate between and during batch processing. Although some currentbatch systems have increased the frequency that they perform eventprocessing (e.g., every two hours; also called near real time systems),there is still time between when the event occurs and when the event isprocessed where data (e.g., account balances) may be in accurate. Thiscan make these systems unsuitable for pre-paid environments or anyenvironment where the right to perform a transaction is based on anaccurate analysis of the balance of an account.

Typically, batch event processing systems (or near real time systems)cannot process an event transactionally as a unit. Accordingly, thesesystems are not applicable where simultaneous events could occur thatwill compete to consume the same account resources (i.e., impact thesame account balance).

Transactional real time event processing systems process events as theyoccur in real time. FIG. 2 shows a real time event processing systemthat processes events in real time. When an event 201 is received by arating engine 203, information needed to rate event 201 is obtained froma database 205. The information in database 205 for rating an event caninclude customer information 207 and A/R 209 as shown.

Once rating engine 203 receives the information from database 205 forrating event 201, rating engine 203 rates event 201 and sends theappropriate changes to the information stored in the database 205 forupdating. Database 205 can also store event 211. In this manner, eventscan be processed transactionally as units. If simultaneous events occurthat are competing for the same resource, the events can be processedserially by locking access to the resource.

Although transactional real time event processing systems can providesignificant advantages over batch processing systems, it would still bedesirable to have improved systems that more efficiently process theevents. Additionally, it will be beneficial if the improved techniquesstill maintained high availability and reliability for the information.

SUMMARY OF THE INVENTION

The invention provides systems and methods for more efficientlyprocessing events, storing information and restoring information. Ingeneral, events can be processed in real time by storing informationthat is needed to rate the event locally, such as in the memory of therating system. As the information for rating the event is availablelocally, it is not necessary to receive the information from a remotedatabase. The rated event can be subsequently stored on a database,which can result in more efficient storing and restoring of theinformation. Several embodiments of the invention are described below.

In one embodiment, the invention provides a method of rating events in areal time transaction processing system. An event is received at arating system and the event is rated at the rating system according toinformation stored locally on the rating system. The rated event canthen be stored on a database system. In some embodiments, rated eventsare classified into multiple classes with different priorities forstorage.

In another embodiment, the invention provides a method of storing eventsin a transaction processing system. Events are grouped for moreefficient storage on a database system. Priorities of the events areanalyzed and the events are stored in groups on the database systemtaking into account the priorities of the events. Typically, thepriorities of the events include times by which events will be stored onthe database system.

In another embodiment, the invention provides a method of restoringinformation in a transaction processing system. Information that waspreviously stored on a database system is retrieved. Additionally, ratedevents that were stored on the database system are retrieved. The ratedevents are applied to the previously stored information in order torestore information stored on the database system.

In another embodiment, the invention provides a method of committingevents in a transaction processing system. One or more transactionthreads process events utilizing read-only data from a shared memory ofan in-memory database. The one or more transaction threads sendinformation regarding a processed event to a commit engine. The commitengine updates the shared memory according to the processed event.Additionally, the commit engine can log the processed event to a storagedevice.

In another embodiment, the invention provides a method of committingevents in a transaction processing system. Events to be committed arereceived where each event has a deadline specifying an amount of timethat can elapse before the event should be committed. The event with theshortest deadline is selected and one or more events that can becommitted with the selected event are identified. The selected event andthe one or more events are committed to a storage device. In someembodiments, the events to be committed are sorted according todeadlines.

Other features and advantages of the invention will become readilyapparent upon review of the following description in association withthe accompanying drawings, where the same or similar structures aredesignated with the same reference numerals.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an event processing system that processes events in batches(e.g., a batch processing system).

FIG. 2 shows an event processing system that processes events in realtime.

FIG. 3 shows a network of multiple computer systems and devices.

FIG. 4 illustrates and example of a computer system that can be utilizedin association with embodiments of the invention.

FIG. 5 illustrates a system block diagram of the computer system of FIG.4.

FIG. 6 shows an example of a real time event processing system accordingto one embodiment of the invention.

FIG. 7 shows a flow chart of a process of rating events that utilizesinformation stored locally on the rating system.

FIG. 8 shows a flow chart of a process of storing events on a databasesystem that includes taking into account priorities of the events.

FIG. 9 shows a flow chart of a process of restoring information thatutilizes previously stored information and rated events.

FIG. 10 shows a transactional real time event processing systemincluding shared memory of an in-memory database.

FIG. 11 shows a flow chart of a process of committing events wheretransaction threads have read-only access to shared memory.

FIG. 12 shows a flow chart of a process of committing events whereevents have associated deadlines for committing.

DETAILED DESCRIPTION OF EMBODIMENTS

Embodiments of the invention are described below with reference topreferred embodiments that rate the events in real time. However, manyaspects of the invention can be advantageously applied to other eventprocessing systems and are therefore not limited to the system, orapplication that is described herein. Accordingly, the description ofthe embodiments is for purposed of illustration and not limitation.

FIG. 3 shows an example of a network. A network 301 providescommunication between and among multiple computer systems 303.Additionally, network 301 can receive information from devices such as acellular (wireless) phone 305 and a conventional telephone 307.

In event processing systems, it should be understood that the rating anddatabase systems are not necessarily on the same computer system 303.Furthermore, FIG. 3 illustrates that events can be received fromnumerous devices including a computer system 303 (such as for on-lineInternet usage), cellular phone 305 (such as for wireless minutes) andtelephone 307 (such as for telephones utilizing the Internet or voiceover IP).

FIG. 4 illustrates and example of a computer system that can be used inassociation with embodiments of the invention. FIG. 4 shows computersystem 303 that includes a display 403, screen 405, cabinet 407,keyboard 409, and mouse 411. Mouse 411 can have one or more buttons forinteracting with a graphical user interface. Cabinet 407 houses a CD-ROMand DRIVE 413 system memory and a hard drive (see FIG. 5), which can beutilized to store and retrieve software programs incorporating computercodes that implements the invention, data for use with the invention,and the like. Although CD-ROM 415 is shown as an exemplary computerreader storage medium, other computer readable storage media includingfloppy disk, tape, flash memory, system memory, and hard drives can beutilized. Additionally, a data signal embodied in a carrier wave (e.g.,in a network including the Internet) can be the computer readablestorage medium.

FIG. 5 shows a system block diagram of computer system 303. As in FIG.4, computer system 303 includes display 403, keyboard 409 and mouse 411.Computer system 303 further includes subsystems such as a centralprocessor 451, system memory 453, fixed storage, 455 (e.g., hard drive)removable storage 457 (e.g., CD-ROM drive), display adapter 459, soundcard 461, speakers 463, and network interface 465. Other computersystems suitable for use with the invention can include additional orfewer subsystems. For example, another computer system could includemore than one processor 451 (i.e., a multi-processor system) or a cachememory.

The system bus architecture of computer system 303 is represented byarrows 467. However, these arrows are illustrative of any connectionscheme serving to link the subsystems. For example, a local bus could beutilized to connect processor 451 to memory 453 and display adapter 459.Computer system 303 shown in FIG. 5 is but an example of a computersystem suitable for use with the invention. Other computer architectureshaving different configurations of subsystems can also be utilized.

As the name implies, event processing systems process events. Events aretypically generated when transactions are completed. For example, if aservice provider is tracking the usage of a cellular telephone then anevent can be generated when the call is complete. The event informationcan include data such as the duration of the call, the time of day,local/long distance, customer, and the like. Although events aretypically generated when a transaction is complete, interim events canalso be generated.

FIG. 6 shows a real time event processing system according to oneembodiment of the invention. An event 501 is rated by a rating engine503. Rating engine 503 receives information for rating event 501 from amemory 505. Memory 505 is local storage for rating engine 503 and caninclude any storage media including memory, hard disks and the like.

Memory 505 is shown to store customer information 507 and A/R 509. Whenrating engine 503 receives event 501, the rating engine retrieves theinformation that is necessary to rate event 501 from memory 505.Accordingly, rating engine 503 can rate event 501 without requiringretrieval of information from a remote database.

After rating event 501, information is sent to a database 511 thatstores customer information 513, A/R 515 and rated events 517. Database511 receives changes to the information stored on the database as aresult of event 501. Additionally, database 511 acts as the permanentstorage for the information and stores rated events 517, which can beutilized to restore information in memory 505 as will be discussedbelow. Typically, the information is stored in a relational databasewhere related tables store the information.

With the embodiment shown in FIG. 6, rated events are stored on thedatabase system. A rated event includes information that has beengenerated when the event was rated. In some embodiments, the ratedevents include information that has changed in the database as a resultof the event. Thus, it is not necessary for database 511 to store allthe specifics of the event, which can result in a significant savings interms of the amount of information stored and the time it takes to storethe information.

As an example, assume that the service provider described above thattracks cellular phone usage utilizing a complex formula for determiningthe cost of a call that includes the duration, time of day, local/longdistance, location of the call, and the like. In some embodiments, thisinformation need not be stored as the rated event can include the amountin which the customers balance has been increased by the event insteadof all the information for rating the event. As will be described inmore detail below, the rated events can also be utilized to restoreinformation and it is not necessary to maintain a redo log.

Memory 505 can store the most up-to-date information so that thisinformation is accurate at all times. Database 511 can be updated withchanges to the information periodically with rated events 517 acting asa log for changes to the database.

Now that an exemplary system has been described, it may be beneficial todescribe a method of rating events according to one embodiment of theinvention. As with all the flow charts shown herein, steps may be added,deleted, combined, and reordered without departing from the spirit andscope of the invention. FIG. 7 shows a flow chart of a process of ratingevents that utilizes information stored locally on the rating engine orsystem.

At a step 601, an event is received. As described above, the event canbe the result of any number of different transactions that need to berated. Additionally, some events are interim events that may begenerated before a transaction is complete. The event is rated accordingto information stored locally at a step 603. Thus, the event is ratedwithout necessitating retrieval of information from a remote databasesystem.

At a step 605, the rated event is stored in a database. The rated eventcan include, among other things, changes to the information on thedatabase that have occurred as a result of rating the event. Thus, therated event includes information that was not included in the event.

With the embodiment shown in FIG. 7, events can be more efficientlyrated and stored. For example, the information for rating the event doesnot need to be retrieved from a remote database and events can be moreefficiently stored because information from the rating process can beutilized.

In some embodiments, events or rated events are classified into multipleclasses with different priorities for storage. As an example, thedifferent priorities can include times by which events will be stored onthe database system. Thus, a service provider can provide differentlevels of service (quality of service or QoS) to different customers.One customer may require that the information be stored within a fewmilliseconds, whereas another customer may find it acceptable to havethe information stored within hundreds of milliseconds.

When the database system is storing events or rated events, the databasesystem can take into account the priorities of the events when storingthem on the database system. FIG. 8 shows a flow chart of a process ofstoring events that takes into account the priorities of the events.

At a step 701, events are grouped for more efficient storage on thedatabase. Grouping events for more efficient storage on the database caninclude analyzing a curve of the hard drive storage efficiency, the harddrive latency, the size of the events, and/or any other information. Asan example, it can be clearly seen that it may be more efficient togroup two events if the events will be stored near the same physicallocation on the hard drive.

The priorities of the events are analyzed at a step 703. The prioritiesof the events can include times by which events will be stored on thedatabase system. Therefore, although it may be efficient to group someevents together, the grouping could result in a storage time that isoutside the priority of one or more of the events. Additionally, thesequence of storing the events can be affected by their priorities suchthat events with a higher priority may be stored before earlier eventswith lower priorities.

At a step 705, the events are stored in groups on the database systemtaking into account the priorities of the events. By giving the eventsdifferent priorities, the service provider is able to offer differentlevels of service to its customers while still maintaining theefficiency of the database system.

The rated events that are stored on the database system can also beutilized to restore information that is stored locally on the ratingsystem. FIG. 9 shows a flow chart of a process of restoring informationto a rating system utilizing previously stored information from adatabase and rated events on the database. An example of when thisprocess could be utilized is when the computer system implementing therating system crashes and the rating system needs to be brought backon-line.

At a step 801, information previously stored on the database isretrieved. Depending on the implementation, the information stored onthe database may be almost up to date or it may be stale. In order tobring the information up-to-date, the rating system also retrieves ratedevents that are stored on the database system at a step 803. The ratedevents include information specifying how the information that is storedon the database has changed as a result of events that wheresubsequently received.

The rated events are applied to the information from the database at astep 805. By applying the rated events to the previously storedinformation, the information stored in the database is restored to itscurrent state. Thus, by retrieving the information previously stored onthe database and the rated events on the database, the rating system isable to restore the current information. Not only is the processefficient, it does not require the storage of a redo log that trackseach change to the database.

It may be beneficial to describe an example of restoring informationaccording to the flow chart shown in FIG. 9. Going back to the examplewhere a service provider is providing cellular time to customers, therated events can result in, among other things, changes to a customer'sbalance.

If it is desired to restore the information on the rating system, thepreviously stored balance for the customer may be retrieved from thedatabase system. Additionally, any subsequent rated events that effectedthis customer's information may be retrieved. The rated events that areretrieved are then applied to the information, where they may update thebalance to the current amount.

The above has described rating of events, the invention can alsoprovides innovative techniques of committing processed events. FIG. 10shows a transactional real time event processing system. An application901 interacts with transaction threads (or processes, contexts, objects,etc.) 903. For example, application can be a business billingapplication that interacts with transaction threads 903 throughapplication programming interface (API) calls.

Each transaction thread 903 is executing computer code to process anevent and can include a rating engine as described above. Transactionthreads 903 have read-only access to a shared memory 905 of an in-memorydatabase. When initializing shared memory, conventional operatingsystems allow the read/write privileges that are granted to bespecified.

Shared memory 905 can store, among other things, customer informationand A/R (e.g., information for determining if a transaction is allowed,rating transactions and balances). By giving transaction threads 903read-only access to shared memory 905, “dirty” reads can be avoidedwhere data can be read from shared memory before it has been committed.This will be described in more detail in the following paragraphs.

As transaction threads 903 have read-only access to shared memory 903,the transaction threads store changes that are made to the shared memoryin scratch pad (local) memory 907. When a transaction thread is ready tocommit a processed event, information is sent to a commit engine 909.

Commit engine 909 updates the shared memory according to the processedevent and can log the processed event to a storage device 911. The logon storage device 911 can serve for failure or disaster recovery.

Since transaction threads 903 do not have write access to shared memory905, the transaction threads do not have access to any updates to theshared memory until after the update has been committed through commitengine 909. This remedies the dirty read problem of many conventionalsystems.

Additionally, transaction threads 903 can provide APIs for application901 to access shared memory 905. This can be especially beneficial ifapplication 901, transaction threads 903 and shared memory 905 are inthe same address space (see dashed lines). By being in the same addressspace, application 901 can access data in shared memory 905 directly,without requiring a copy of the data being made and sent.

FIG. 11 shows a flow chart of a process of committing events wheretransaction threads have read-only access to shared memory. At a step1001, one or more transaction threads process events utilizing read-onlydata from a shared memory of an in-memory database. The processing caninclude rating an event.

At a step 1003, the one or more transaction threads send informationregarding a processed event to a commit engine. For example, atransaction thread can send the processed event and data from scratchpad memory 907.

The commit engine updates the shared memory according to the processedevent at a step 1005. Additionally, the commit engine can store a log ofthe event in a storage device. In some embodiments, the processed eventand local memory are logged on a storage device. Updates to the sharedmemory of the in-memory database are then made according to theprocessed event. Lastly, events are extracted from the log and stored inanother database.

The way in which events are committed can have a large impact on theefficiency of the system. FIG. 12 shows a flow chart of a process ofcommitting events where events have associated deadlines for committing.The deadlines specify an amount of time that can elapse before the eventshould be committed. The event can be committed at any time before thedeadline, but the deadline should or must not be missed.

At a step 1101, events to be committed are received where each event hasa deadline. Some events may need to be committed relatively fast (e.g.,milliseconds) and others may have longer deadlines. Events that do nothave an associated deadline can still be committed in timely manner aswill be described below.

An event with the shortest deadline is selected at a step 1103. Thecommit engine may be continually committing events. Thus, if there areno events with deadlines waiting to be committed, an event without adeadline can be selected (e.g., longest waiting to be committed). Insome embodiments, the events are sorted by deadlines in order tofacilitate selecting the event with the shortest deadline.

At a step 1105, one or more events are identified that can be committedwith the selected event. Although the commit engine could commit oneevent at a time, it can be more efficient to commit multiple events at atime. The efficiency of committing multiple events can be analyzed todetermine how many additional events to commit with the selected event.For example, any one or more of factors such as the speed of the storagedevice, size of the events, maximum size for committing, maximum delaytime for committing, preprocessing overhead time for the commit,postprocessing overhead time for the commit, or the like.

At a step 1107, the selected event and the one or more events identifiedat step 1105 are committed. As an example, assume that the events aresorted and the event with the shortest deadline is selected. The commitengine could determine that the next five events (with or withoutdeadlines) could be efficiently committed with the selected event (e.g.,disk drives can often perform additional writes much more efficientlythan sequential single writes). In other words, committing these sixevents would be more efficient than committing just the selected eventand still allow deadlines on existing and future events to be met.Accordingly, the six events would be committed together.

As can be seen, the invention allows for very efficient ratings andcommitting of events while also maintaining the integrity of theinformation. Additionally, the storage and retrieval of the informationcan also be improved utilizing embodiments of the invention.

While the above has described specific embodiments of the invention,various alternatives and modifications can be made to the embodimentsdescribed above. However, these alternatives and modifications are notoutside the scope of the invention which is defined by the followingclaims along with their fair scope of equivalents.

1. A method of rating events in a real time transaction processingsystem, comprising: receiving an event at a rating system; rating theevent at the rating system according to information stored locally onthe rating system; and storing the rated event on a database system. 2.The method of claim 1, wherein the information is stored locally on therating system in memory.
 3. The method of claim 1, wherein rated eventsare classified into a plurality of classes with different priorities forstorage.
 4. The method of claim 3, wherein the different prioritiesinclude times by which events will be stored on the database system. 5.The method of claim 4, further comprising grouping rated events togetherfor more efficient storage on the database system while taking intoaccount the different priorities of the rated events.
 6. The method ofclaim 1, further comprising restoring information stored locally on therating system by retrieving previous information stored on the databasesystem, retrieving rated events stored on the database system, andapplying the rated events to the information.
 7. A computer programproduct for rating events in a real time transaction processing system,comprising: computer code that receives an event at a rating system;computer code that rates the event at the rating system according toinformation stored locally on the rating system; computer code thatstores the rated event on a database system; and a computer readablemedium that stores the computer codes.
 8. The computer program productof claim 7, wherein the computer readable medium is one of a CD-ROM,floppy disk, tape, flash memory, system memory, hard drive, or datasignal embodied in a carrier wave.
 9. A method comprising: receiving, bya computer system, a plurality of events representing messages abouton-line or wireless transactions, the plurality of events including: afirst event representing completion of a first cellular phone call by afirst cellular phone user and including information pertaining to thefirst cellular phone call; and a second event representing completion ofa second cellular phone call by a second cellular phone user andincluding information pertaining to the second cellular phone call;grouping, by the computer system, the first and second events together,the grouping comprising analyzing at least one of a curve of a harddrive storage efficiency, a hard drive latency and a size of the events;analyzing, by the computer system, a priority for the first event and apriority for the second event, the priority for the first event beingbased on a quality of service defined for the first cellular phone userand the priority for the second event being based on a quality ofservice defined for the second cellular phone user; and storing, by thecomputer system, the first and second events as a group on the database,the storing taking into account the priorities of the first and secondevents such that, if the priority for the first event is higher than thepriority for the second event, the first event is stored before thesecond event, and if the priority for the second event is higher thanthe priority for the first event, the second event is stored before thefirst event, wherein the receiving, grouping, analyzing, and storing areperformed by the computer system in real time. 10-11. (canceled)
 12. Acomputer readable medium for a computer system, the computer readablemedium having stored thereon a series of instructions which, whenexecuted by a processing component, cause the processing component to:receive a plurality of events representing messages about on-line orwireless transactions, the plurality of events including: a first eventrepresenting completion of a first cellular phone call by a firstcellular phone user and including information pertaining to the firstcellular phone call; and a second event representing completion of asecond cellular phone call by a second cellular phone user and includinginformation pertaining to the second cellular phone call; group thefirst and second events together, the grouping comprising analyzing atleast one of a curve of a hard drive storage efficiency, a hard drivelatency and a size of the events; analyze a priority for the first eventand a priority for the second event, the priority for the first eventbeing based on a quality of service defined for the first cellular phoneuser and the priority for the second event being based on a quality ofservice defined for the second cellular phone user; and store the firstand second events as a group on the database, the storing taking intoaccount the priorities of the first and second events such that, if thepriority for the first event is higher than the priority for the secondevent, the first event is stored before the second event, and if thepriority for the second event is higher than the priority for the firstevent, the second event is stored before the first event, wherein thereceiving, grouping, analyzing, and storing are performed by theprocessing component in real time.
 13. The computer readable medium ofclaim 12, wherein the computer readable medium is one of a CD-ROM,floppy disk, tape, flash memory, system memory, or hard drive.
 14. Amethod of restoring information in a transaction processing system,comprising: retrieving information previously stored on a databasesystem; retrieving rated events from the database system; and applyingthe rated events to the previously stored information in order torestore information stored on the database system.
 15. The method ofclaim 14, wherein the information is restored on a rating system. 16.The method of claim 14, wherein the rated events include informationthat was not included in a corresponding event that was rated.
 17. Acomputer program product for restoring information in a transactionprocessing system, comprising: computer code that retrieves informationpreviously stored on a database system; computer code that retrievesrated events from the database system; and computer code that appliesthe rated events to the previously stored information in order torestore information stored on the database system; and a computerreadable medium that stores the computer codes.
 18. The computer programproduct of claim 17, wherein the computer readable medium is one of aCD-ROM, floppy disk, tape, flash memory, system memory, hard drive, ordata signal embodied in a carrier wave.
 19. A method of committingevents in a transaction processing system, comprising: one or moretransaction threads processing events utilizing read-only data from ashared memory of an in-memory database; the one or more transactionthreads sending information regarding a processed event to a commitengine; and the commit engine updating the shared memory according tothe processed event.
 20. The method of claim 19, further comprising thecommit engine logging the processed event to a storage device.
 21. Themethod of claim 19, wherein there are a plurality of transactionthreads, each for processing an event.
 22. The method of claim 19,wherein the one or more transaction threads stores updates to the sharedmemory in a local memory.
 23. The method of claim 22, wherein the one ormore transaction threads sends information regarding the local memory tothe commit engine.
 24. The method of claim 19, further comprising anapplication that interacts with the one or more transaction threads. 25.The method of claim 24, wherein the application, the one or moretransaction threads and the shared memory in are in a same addressspace.
 26. A transaction processing system, comprising: a shared memoryof an in-memory database; one or more transaction threads that processevents utilizing read-only access to the shared memory; a commit enginethat receives information regarding a processed event and updates theshared memory according to the processed event.
 27. The system of claim26, further comprising a storage device that logs the processed event.28. The system of claim 26, further comprising an application thatinteracts with the one or more transaction threads.
 29. The system ofclaim 28, wherein the application, the one or more transaction threadsand the shared memory in are in a same address space.
 30. A method ofcommitting events in a transaction processing system, comprising:receiving events to be committed, each event having a deadlinespecifying an amount of time that can elapse before the event should becommitted; selecting an event with a shortest deadline; identifying oneor more events that can be committed with the selected event; andcommitting the selected event and the one or more events to a storagedevice.
 31. The method of claim 30, further comprising sorting theevents to be committed according to deadlines.
 32. The method of claim30, wherein identifying the one or more events comprises analyzing theefficiency of committing multiple events.
 33. The method of claim 32,wherein one or more of a speed of the storage device, size of the one ormore events, a maximum size, a maximum delay time, a preprocessingoverhead time, or postprocessing overhead time are analyzed.
 34. Acomputer program product that commits events in a transaction processingsystem, comprising: computer code that receives events to be committed,each event having a deadline specifying an amount of time that canelapse before the event should be committed; computer code that selectsan event with a shortest deadline; computer code that identifies one ormore events that can be committed with the selected event; computer codethat commits the selected event and the one or more events to a storagedevice; and a computer readable medium that stores the computer codes.35. The computer program product of claim 34, wherein the computerreadable medium is one of a CD-ROM, floppy disk, tape, flash memory,system memory, hard drive, or data signal embodied in a carrier wave.36-39. (canceled)
 40. The method of claim 9, wherein the characteristicindicates that the first and second events will be stored near a samephysical location on a hard disk of the database.
 41. The method ofclaim 9, wherein the quality of service defined for the first cellularphone user indicates a time by which the first event should be stored inthe database, and wherein the quality of service defined for the secondcellular phone user indicates a time by which the second event should bestored in the database.
 42. The method of claim 9 further comprising,prior to the storing: rating the first event by determining, based onthe information pertaining to the first cellular phone call, a cost forthe first cellular phone call; and rating the second event bydetermining, based on the information pertaining to the second phonecall, a cost for the second phone call.
 43. The method of claim 42,wherein the information pertaining to the first cellular phone callinclude a duration and a time of day of the first cellular phone call,and wherein the information pertaining to the second cellular phone callinclude a duration and a time of day of the second cellular phone call.44. (canceled)
 45. The computer readable medium of claim 12, wherein theseries of instructions further cause the processing component to, priorto the storing: rate the first event by determining, based on theinformation pertaining to the first cellular phone call, a cost for thefirst cellular phone call; and rate the second event by determining,based on the information pertaining to the second phone call, a cost forthe second phone call.
 46. The computer readable medium of claim 45,wherein the information pertaining to the first cellular phone callinclude a duration and a time of day of the first cellular phone call,and wherein the information pertaining to the second cellular phone callinclude a duration and a time of day of the second cellular phone call.47. The computer readable medium of claim 12, wherein the characteristicindicates that the first and second events will be stored near a samephysical location on a hard disk of the database.
 48. The computerreadable medium of claim 12, wherein the quality of service defined forthe first cellular phone user indicates a time by which the first eventshould be stored in the database, and wherein the quality of servicedefined for the second cellular phone user indicates a time by which thesecond event should be stored in the database.